home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
ietf
/
snmpsec
/
91jul.min
next >
Wrap
Text File
|
1993-02-17
|
9KB
|
220 lines
CURRENT_MEETING_REPORT_
Reported by James Galvin/TIS and Keith McCloghrie/Hughes
SNMPSEC Minutes
Status of the Documents Reviewed:
o All three: the SNMP Administrative Framework, SNMP Security
Protocols, and SNMP Party MIB, were published as Internet Drafts
immediately after the previous IETF (in St. Louis).
o An update to the SNMP Party MIB was distributed to the snmp-sec-dev
mailing-list at the beginning of July.
The Outstanding Issues were Discussed:
o Mike St.Johns suggested consideration of the use of ``threshold
keying'', in the distribution of initial secrets. Threshold keying
is a standard security technique (see Denning's book on Computer
Security), in which the keys are split into multiple ``shadow''
parts. The parts could be distributed separately and then
recombined to obtain the initial secret. Use of this technique
would allow an administration to, for example, have a single shadow
key which would be manually entered into each agent at install
time, and another shadow key calculated by the nms so as to be
agent-specific and distributed to the agent; these two parts could
then be combined to get the initial secret. The advantages would
be the ability to have the manually distributed secret information
be a) the same for all agents, and b) different from the secret
used as the initial key. The disadvantage being the special
first-time-only processing the agent would need to recombine the
keys. The meeting agreed to consider the suggestion in parallel
with other activities.
o The differences between MD4 and MD5 were discussed, and the pros
and cons of using each. A suggestion was made to update the text
of the SNMP Security Protocols document to replace occurrences of
``SNMP MD4 Authentication Protocol`` by ``SNMP Digest
Authentication Protocol'' in discussions of all parts of the
protocol except the particular digest algorithm used, where the use
of ``MD4'' would be retained. This suggestion was accepted since
it would minimize the text (e.g. to one page) which would be
needed in a future memo specifying alternative digest algorithms.
o A question on ``wildcard'' parties (analogous to the ``public''
community) was answered by discussing the ``initial'' noAuth,noPriv
parties defined by convention in the Party MIB. A lively discussion
ensued on the access rights to be afforded to this out-of-the-box
noAuth,noPriv party. Some argued for allowing read-access to
1
everything in the MIB (except SNMP security's secret information);
others for allowing read-access to nothing, or just to MIB-II's
system group. The consensus of the discussion seemed to be for
this working group to stay silent on the issue, and let the various
Requirements working groups make device-type specific
recommendations. The Router Requirements WG. is making such a
recommendation for use of ``public'' communities, and knows it will
have to update that recommendation as and when the SNMP Security
documents are further along.
o A discussion was held on the protocol's use of ASN.1 tags instead
of a version number field. The same conclusion was reached as in
previous discussions of the same topic.
o The term ``random values'' in the section of the SNMP Security
Protocols document discussing what to do when an agent loses its
knowledge of a secret, was clarified as being the need to set the
values to non-valid or non-guessable values.
There was discussion of the implementation experience gained so far:
o Three separate implementations were in various stages of
incompletion, and one other person had spent some preparing for an
implementation. Two of these implementations interoperated with
each other using noAuth,noPriv. Two had implemented MD4. One was
using DES but was unsure that the encrypted data was correct. To
date, there is no experience with multiple MIB views, proxy, clock
synchronization, nor SNMP access to the Party MIB.
o A couple of ASN.1 definitions were discussed for possible
optimizations:
- The replacement of ANY by a CHOICE in types of AuthInformation,
- The specification of a fixed length for the OCTET STRING
containing the digest value, and
- The rearrangement of the authentication information and the
source/destination party fields leading to the removal of one
of the levels of serialization.
There was also discussion of the present access-control
granularity, and its ability to scale. The definition of MIB
subviews does allow access control on individual instances, but at
the cost of entering each object instance in the View Table. There
is a legitimate requirement to support several Views each
containing all the variables in, for example, the ifTable for just
one interface. This requires a large number of entries in the View
2
Table even with only a moderate numbers of interfaces.
The document editors agreed to update the documents to reflect the
(minor) changes resulting from the above discussions. These
updates are expected to be available by the end of August.
Finally, there was discussion of where to go next. The general
consensus of the meeting was that SNMP Security was too important
and central to the technology for us to recommend progression in
the standards track with the present incomplete levels of
implementation experience. When asked how many other
implementation efforts were planned for the near future, a half a
dozen attendees raised their hands. These and others were strongly
encouraged to proceed with these implementations in order to gain
the required experience. Interoperability testing of such
implementations across the Internet, and at the Interop '91
SNMP-demo ``staging'' event were discussed and encouraged.
Attendees
Steve Alexander stevea@i88.isc.com
Karl Auerbach karl@eng.sun.com
Doug Barlow barlow@decwet.dec.com
James Barnes barnes@xylogics.com
Steve Bostock steveb@novell.com
Howard Brown brown@ctron.com
Theodore Brunner tob@thumper.bellcore.com
John Burruss jburruss@wellfleet.com
Jeffrey Case case@cs.utk.edu
Gigi Chu gigic@hpspd.spd.hp.com
John Cook cook@chipcom.com
Tracy Cox tacox@sabre.bellcore.com
Emil Datability
James Davin jrd@ptt.lcs.mit.edu
Jeffrey Edelheit edelheit@mitre.org
Gary Ellis garye@hpspd.spd.hp.com
Bill Fardy fardy@ctron.com
Barbara Fraser byf@cert.sei.cmu.edu
Jeff Fried jmf@relay.proteon.com
Deborah Futcher dfutche@eco.twg.com
Maria Gallagher maria@nsipo.arc.nasa.gov
Shawn Gallagher gallagher@quiver.enet.dec.com
James Galvin galvin@tis.com
Ron Jacoby rj@sgi.com
Mike Janson mjanson@mot.com
Frank Kastenholz kasten@europa.clearpoint.com
Manu Kaycee kaycee@trlian.enet.dec.com
Mark Kepke mak@hpcndk.cnd.hp.com
Kenneth Key key@cs.utk.edu
Christopher Kolb kolb@psi.com
Deidre Kostick dck2@sabre.bellcore.com
Bobby Krupczak rdk@cc.gatech.edu
3
Cheryl Krupczak cheryl@cc.gatech.edu
Nik Langrind nik@shiva.com
Anthony Lauck lauck@tl.enet.dec.com
Tim Lee-Thorp ngc!tim@uunet.uu.net
Ron Mackey rem@dsiinc.com
Keith McCloghrie kzm@hls.com
Evan McGinnis bem@3com.com
Lynn Monsanto monsanto@eng.sun.com
Bradford Parker brad@cayman.com
David Perkins dperkins@synoptics.com
John Pickens jrp@3com.com
Brian Price brian@bss.com
Anil Rijsinghani anil@levers.enet.dec.com
Kary Robertson kr@concord.com.kr
Jonathan Saperia saperia@tcpjon.enet.dec.com
Mark Schaefer schaefer@davidsys.com
John Seligson johns@ultra.com
Ron Sharp rls@neptune.att.com
Anil Singhal nsinghal@hawk.ulowell.edu
Mark Sleeper mws@sparta.com
Michael St. Johns stjohns@umd5.umd.edu
Bob Stewart rlstewart@eng.xyplex.com
Bruce Taber taber@interlan.com
Ronald Tencati tencati@nssdca.gsfc.nasa.gov
Glenn Trewitt trewitt@nsl.dec.com
Theodore Tso tytso@mit.edu
William Versteeg bvs@nrc.com
David Waitzman djw@bbn.com
Steven Waldbusser waldbusser@andrew.cmu.edu
Drew Wansley dwansley@secola.columbia.ncr.com
David Ward dward@chipcom.com
Mark Wood markl@dsiinc.com
Brian Yasaki bky@eco.twg.com
Jeff Young jsy@cray.com
Joseph Zur fibrontics!zur@uunet.uu.net
4